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Abstract 


This memo specifies requirements for a framework and protocols for 
accessing and updating Internet Media Guide (IMG) information for 
media-on-demand and multicast applications. These requirements are 
designed to guide choice and development of IMG protocols for 
efficient and scalable delivery. 
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Le 


Introduction 


Background and Motivation 


For some ten years, multicast-based (multimedia) conferences 
(including IETF working group sessions) as well as broadcasts of 
lectures/seminars, concerts, and other events have been used in the 
Internet, more precisely, on the MBONE. Schedules and descriptions 
for such multimedia sessions as well as the transport addresses, 
codecs, and their parameters have been described using the Session 
Description Protocol (SDP) [2] as a rudimentary (but as of then 
largely sufficient) means. Descriptions have been disseminated using 
the Session Announcement Protocol (SAP) [3] and Session Directory 
Tools such as SD [4] or SDR [5]; descriptions have also been put up 
on web pages, sent by electronic mail, etc. 


Recently, interest has grown to expand -- or better: to generalize -- 
the applicability of these kinds of session descriptions. 
Descriptions are becoming more elaborate in terms of included 
metadata, more generic regarding the types of media sessions, and 
possibly also support other transports than just IP (e.g., legacy TV 
channel addresses). This peers well with the DVB (Digital Video 
Broadcasting) [6] Organization’s increased activities towards IP- 
based communications over satellite, cable, and terrestrial radio 
networks, also considering IP as the basis for TV broadcasts and 
further services. The program/content descriptions are referred to 
as Internet Media Guides (IMGs) and can be viewed as a generalization 
of Electronic Program Guides (EPGs) and multimedia session 
descriptions. 


An Internet Media Guide (IMG) has a structured collection of 
multimedia session descriptions expressed using SDP, SDPng [7], or 
some similar session description format. This is used to describe a 
set of multimedia services (e.g., television program schedules, 
content delivery schedules) but may also refer to other networked 
resources including web pages. IMGs provide the envelope for 
metadata formats and session descriptions defined elsewhere with the 
aim of facilitating structuring, versioning, referencing, 
distributing, and maintaining (caching, updating) such information. 


The IMG metadata may be delivered to a potentially large audience, 
who uses it to join a subset of the sessions described, and who may 
need to be notified of changes to this information. Hence, a 
framework for distributing IMG metadata in various different ways is 
needed to accommodate the needs of different audiences: For 
traditional broadcast-style scenarios, multicast-based (push) 
distribution of IMG metadata needs to be supported. Where no 
multicast is available, unicast-based push is required, too. 
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Furthermore, IMG metadata may need to be retrieved interactively, 
similar to web pages (e.g., after rebooting a system or when a user 
is browsing after network connectivity has been re-established). 
Finally, IMG metadata may be updated as time elapses because content 
described in the guide may be changed: for example, the airtime of an 
event such as a concert or sports event may change, possibly 
affecting the airtime of subsequent media. This may be done by 
polling the IMG sender as well as by asynchronous change 
notifications. 


Furthermore, any Internet host can be a sender of content and thus an 
IMG sender. Some of the content sources and sinks may only be 
connected to the Internet sporadically. Also, a single human user 
may use many different devices to access metadata. Thus, we envision 
that IMG metadata can be sent and received by, among others, cellular 
phones, Personal Digital Assistants (PDAs), personal computers, 
streaming video servers, set-top boxes, video cameras, and Digital 
Video Recorders (DVRs), and that the data be carried across arbitrary 
types of link layers, including bandwidth-constrained mobile 
networks. However, generally we expect IMG senders to be well- 
connected hosts. 


Finally, with many potential senders and receivers, different types 
of networks, and presumably numerous service providers, IMG metadata 
may need to be combined, split, filtered, augmented, modified, etc., 
on their way from the sender(s) to the receiver(s) to provide the 
ultimate user with a suitable selection of multimedia services 
according to her preferences, subscriptions, location, and context 
(e.g., devices, access networks). 


1.2. Scope of This Document 


This document defines requirements that Internet Media Guide 
mechanisms must satisfy in order to deliver IMG metadata to a 


potentially large audience. Since IMGs can describe many kinds of 
multimedia content, IMG methods are generally applicable to several 
scenarios. 


In considering wide applicability, this document provides the problem 
statement and discusses existing mechanisms in this area. Then 
several use case scenarios for IMGs are explained including 
descriptions of how IMG metadata and IMG delivery mechanisms 
contribute to these scenarios. Following this, this document 
provides general requirements that are independent of any transport 
layer mechanism and application, such as delivery properties, 
reliability, and IMG descriptions. 
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This document reflects investigating work on delivery mechanisms for 
IMGs and generalizing work on session announcement and initiation 
protocols, especially in the field of the MMUSIC working group (SAP, 
SIP [8], SDP). 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 


2.1. New Terms 


Internet Media Guide (IMG): IMG is a generic term used to describe 
the formation, delivery, and use of IMG metadata. The 
definition of the IMG is intentionally left imprecise. 


IMG Element: The smallest atomic element of metadata that can be 
transmitted separately by IMG operations and referenced 
individually from other IMG elements. 


IMG Metadata: A set of metadata consisting of one or more IMG 
elements. IMG metadata describes the features of multimedia 
content used to enable selection of and access to media 
sessions containing content. For example, metadata may consist 
of the URI, title, airtime, bandwidth needed, file size, text 
summary, genre, and access restrictions. 


IMG Delivery: The process of exchanging IMG metadata in terms of both 
large-scale and atomic data transfers. 


IMG Sender: An IMG sender is a logical entity that sends IMG metadata 
to one or more IMG receivers. 


IMG Receiver: An IMG receiver is a logical entity that receives IMG 
metadata from an IMG sender. 


IMG Transceiver: An IMG transceiver combines an IMG receiver and 
sender. It may modify received IMG metadata or merge IMG 
metadata received from several different IMG senders. 


IMG Operation: An atomic operation of an IMG transport protocol, used 
between IMG sender (s) and IMG receiver (s) for the delivery of 


IMG metadata and for the control of IMG sender (s)/receiver (s). 


IMG Transport Protocol: A protocol that transports IMG metadata from 
an IMG sender to IMG receiver (s). 
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IMG Transport Session: An association between an IMG sender and one 
or more IMG receivers within the scope of an IMG transport 
protocol. An IMG transport session involves a time-bound 
series of IMG transport protocol interactions that provide 
delivery of IMG metadata from the IMG sender to the IMG 
receiver (s). 


3. Problem Statement 


As we enumerate the requirements for IMGs, it will become clear that 
they are not fully addressed by the existing protocols. The 
"Framework for the Usage of Internet Media Guides" [9] discusses 
about these issues in more detail. 


The MMUSIC working group has long been investigating content, media 
and service information delivery mechanisms, and protocols, and has 
itself produced the Session Announcement Protocol (SAP), the Session 
Description Protocol (SDP), and the Session Initiation Protocol 
(SIP). SDP is capable of describing multimedia sessions (i.e., 
content in a wider sense) by means of limited descriptive information 
intended for human perception plus transport, scheduling information, 
and codecs and addresses for setting up media sessions. SIP and SAP 
are protocols to distribute these session descriptions. 


However, we perceive a lack of a standard solution for scalable IMG 
delivery mechanism in the number of receivers with consistency of IMG 
metadata between an IMG sender and IMG receiver for both bi- 
directional and unidirectional transport. With increased service 
dynamics and complexity, there is an increased requirement for 
updates to these content descriptions. 


HTTP [10] is a well-known information retrieval protocol using bi- 
directional transport and is widely used to deliver web-based content 
descriptions to many hosts. However, it has well-recognized 
limitations of scalability in the number of HTTP clients since it 
relies on the polling mechanism to keep information consistent 
between the server and client. 


SAP [3] is an announcement protocol that distributes session 
descriptions via multicast. It does not support prioritization or 
fine-grained metadata selection and update notifications, as it 
places restrictions on metadata payload size and always sends the 
whole metadata. It requires a wide-area multicast infrastructure for 
it to be deployable beyond a local area network. 
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SIP [8] and SIP-specific event notifications [11] can be used to 
notify subscribers of the update of IMG metadata for bi-directional 
transport. However, it is necessary to define an event package for 
IMGs. 


We also perceive a lack of standard solution for flexible content 
descriptions to support a multitude of application-specific metadata 
and associated data models with a different amount of detail and 
different target audiences. 


SDP [2] has a text-encoded syntax to specify multimedia sessions for 
announcements and invitations. It is primarily intended to describe 
client capability requirements and enable client application 
selection. Although SDP is extensible, it has limitations such as 
structured extensibility and capability to reference properties of a 
multimedia session from the description of another session. 


These can mostly be overcome by the XML-based SDPng [7] -- which is 
intended for both two-way negotiation and unidirectional delivery -- 
or similar content description mechanisms. Since SDPng addresses 


multiparty multimedia conferences, it would be necessary to extend 
the XML schema in order to describe general multimedia content. 


4. Use Cases Requiring IMGs 
4.1. Connectivity-based Use Cases 
4.1.1. IP Datacast to a Wireless Receiver 


IP Datacast is the delivery of IP-based services over broadcast 
radio. Internet content delivery is therefore unidirectional in this 
case. However, there can be significant benefits from being able to 
provide rich media one-to-many services to such receivers. 


There are two main classes of receiver in this use case: fixed 
mains-powered and mobile battery-powered. Both of these are affected 
by radio phenomena and so robust, or error-resilient, delivery is 
important. Carouselled metadata transfer (cyclically repeated with a 
fixed bandwidth) provides a base level of robustness for an IP 
datacast-based announcement system, although the design of 
carouselled transfer should enable battery-powered receivers to go 
through periods of sleep to extend their operational time between 
charges. Insertion of Forward Error Correction (FEC) data into 
metadata announcements improves error resilience, and reordering 
(interleaving) data blocks further increases tolerance to burst 
errors. 
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To enable receivers to more accurately specify the metadata they are 
interested in, the unidirectional delivery may be distributed between 
several logical channels. This is so that a receiver needs only 
access the channels of interest and thus can reduce the amount of 
time, storage, and CPU resources needed for processing the IP data. 
Also, hierarchical channels enable receivers to subscribe to a 
(possibly well-known) root multicast channel/group and progressively 
access only those additional channels based on metadata in parent 
channels. 


In some cases, the receiver may have multiple access interfaces 
adding bi-directional communications capability. This enables a 
multitude of options, but most important, it enables NACK-based 
reliability and the individual retrieval of missed or not-multicast 
sets of metadata. 


Thus, essential IMG features in this case include the following: 
robust unidirectional delivery (with optional levels of reliability 
including "plug-in FEC" supported by a transport layer protocol), 
which implies easily identifiable segmentation of delivery data to 
make FEC, carousel, interleaving, and other schemes possible; 
effective identification of metadata sets (probably uniquely) to 
enable more efficient use of multicast and unicast retrieval over 
multiple access systems regardless of the parts of metadata and 
application-specific extensions in use; and prioritization of 
metadata, which can (for instance) be achieved by spreading it 
between channels and allocating/distributing bandwidth accordingly. 


Furthermore, some cases require IMG metadata authentication and some 
group security/encryption and supporting security message exchanges 
(out of band from the IMG multicast sessions). 


4.1.2. Regular Fixed Dial-up Internet Connection 
Dial-up connections tend to be reasonably slow (<56 kbps in any 


case), and thus large data transfers are less feasible, especially 
during an active application session (such as a file transfer 


described by IMG metadata). They can also be intermittent, 
especially if a user is paying for the connected time, or connected 
through a less reliable exchange. Thus, this favors locally stored 


IMG metadata over web-based browsing, especially where parts of the 
metadata change infrequently. There may be no service provider 
preference over unicast and multicast transport for small and medium 
numbers of users as the last-mile dial-up connection limits per-user 
congestion, and a user may prefer the more reliable option (unicast 
unless reliable multicast is provided). 
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4.1.3. Broadband Always-on Fixed Internet Connection 


Typically, bandwidth is less of an issue to a broadband user and 
unicast transport, such as using query-response methods, may be 
typical for a PC user. If a system were only used in this context, 
with content providers, ISPs, and users having no other requirements, 
then web-based browsing may be equally suitable. However, broadband 
users sharing a local area network, especially wireless, may benefit 
more from local storage features than on-line browsing, especially if 
they have intermittent Internet access. 


Some services on broadband, such as live media broadcasting, benefit 
from multicast transport for streaming media because of scalability. 
In the cases where multicast transport is already available, it is 
convenient for a sender and receiver to retrieve IMG metadata over 
multicast transport. Thus, broadband users may be forced to retrieve 
IMG metadata over multicast if backbone operators require this to 
keep system-wide bandwidth usage feasible. 


4.2. Content-orientated Use Cases 


IMGs will be able to support a very wide range of use cases for 
enabling content/media delivery. The following few sections just 
touch the surface of what is possible and are intended to provide an 
understanding of the scope and type of IMG usage. Many more examples 
may be relevant, for instance, those detailed in [12]. There are 
several unique features of IMGs that set them apart from related 
application areas such as Service Location Protocol (SLP) based 
service location discovery, Lightweight Directory Access Protocol 
(LDAP) based indexing services, and search engines such as Google. 
Features unique to IMGs include the following: 


o IMG metadata is generally time-related 


o There are timeliness requirements in the delivery of IMG 
metadata 


o IMG metadata may be updated as time elapses or when an event 
arises 


4.2.1. TV and Radio Program Delivery 


A sender of audio/video streaming content can use the IMG metadata to 
describe the scheduling and other properties of audio/video sessions 
and events within those sessions, such as individual TV and radio 
programs and segments within those programs. IMG metadata describing 
audio/video streaming content could be represented in a format 
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similar to that of a TV guide in newspapers, or an Electronic Program 
Guide available on digital TV receivers. 


TV and radio programs can be selected for reception either manually 
by the end-user or automatically based on the content descriptions 
and the preferences of the user. The received TV and radio content 
can be either presented in real time or recorded for later 
consumption. There may be changes in the scheduling of a TV ora 
radio program, possibly affecting the transmission times of 


subsequent programs. IMG metadata can be used to notify receivers of 
such changes, enabling users to be prompted or recording times to be 
adjusted. 


4.2.2. Media Coverage of a Live Event 


The media coverage of a live event such as a rock concert or a sports 
event is a special case of regular TV/radio programming. There may 
be unexpected changes in the scheduling of a live event, or the event 
may be unscheduled to start with (such as breaking news). In 
addition to audio/video streams, textual information relevant to the 
event (e.g., statistics of the players during a football match) may 
be sent to user terminals. Different transport modes or even 
different access technologies can be used for the different media: 
for example, a unidirectional datacast transport could be used for 
the audio/video streams and an interactive cellular connection for 
the textual data. IMG metadata should enable terminals to discover 
the availability of different media used to cover a live event. 


4.2.3. Distance Learning 


IMG metadata could describe compound sessions or services enabling 
several alternative interaction modes between the participants. For 
example, the combination of one-to-many media streaming, unicast 
messaging, and downloading of presentation material could be useful 
for distance learning. 


4.2.4. Multiplayer Gaming 


Multiplayer games are an example of real-time multiparty 
communication sessions that could be advertised using IMGs. A gaming 
session could be advertised either by a dedicated server or by the 
terminals of individual users. A user could use IMGs to learn of 
active multiplayer gaming sessions, or advertise the user’s interest 
in establishing such a session. 
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.2.5. File Distribution 


IMGs support the communication of file delivery session properties, 
enabling the scheduled delivery or synchronization of files between a 
number of hosts. The received IMG metadata could be subsequently 
used by any application (also outside the scope of IMGs), for 
example, to download a file with a software update. IMG metadata can 
provide a description to each file in a file delivery session, 
assisting users or receiving software in selecting individual files 
for reception. 


For example, when a content provider wants to distribute a large 
amount of data in file format to thousands of clients, the content 
provider can use IMG metadata to schedule the delivery effectively. 


Since IMG metadata can describe time-related data for each receiver, 
the content provider can schedule delivery time for each receiver. 
This can save network bandwidth and delivery capacity of senders. In 
addition, IMG metadata can be used to consistency check, and thus 
synchronize, a set of files between a sender host and receiver host, 
when those files change as time elapses. 


.2.6. Coming-release and Pre-released Content 


IMG metadata Can be used to describe items of content before the 
details of their final release are known. A user may be interested 
in coming content (a new movie or software title where some aspects 
of the content description are known in advance) and so subscribe to 
an information service that notifies the user of changes to metadata 
describing that content. Thus, as the coming release (or pre- 
releases, e.g., as movie trailers or software demos) become 
available, the IMG metadata changes and the user is notified of this 
change. For example, the user could see an announcement of a movie 
that will be released sometime in the next few months, and configure 
the user's terminal to receive and record any trailers or promotional 
material as they become available. 


Requirements 


.1. General Requirements 


.1.1. Independence of IMG Operations from IMG Metadata 


REO GEN-1: Carrying different kinds of IMG metadata format and 
different IMG metadata formats in the IMG message body MUST be 
allowed. 
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REQ GEN-2: Delivery mechanisms SHOULD support many different 
applications’ specific metadata formats to keep the system 
interoperable with existing applications. 


This provides flexibility in selecting/designing an IMG transport 
protocol suited to various scenarios. 


5.1.2. Multiple IMG Senders 


REQ GEN-3: IMG receivers MUST be allowed to communicate with any 
number of IMG senders simultaneously. 


This might lead to receiving redundant IMG metadata describing the 
same items; however, it enables the IMG receiver access to more IMG 
metadata than may be available from a single IMG sender. This also 
provides flexibility for the IMG transport protocols and does not 
preclude a mechanism to solve inconsistency among IMG metadata due to 
multiple IMG senders. This document assumes that a typical IMG 
environment will involve many more IMG receivers than IMG senders and 
that IMG senders are continually connected for the duration of 
interest (rather than intermittently connected). 


5.1.3. Modularity 


REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of 
several IMG operations. 


This is for the purpose of extending functionality (e.g., several or 
one protocol(s) to provide all the needed operations). Applications 
can select an appropriate operation set to fulfill their purpose. 


5.2. Delivery Properties 


This section describes general performance requirements based on the 
assumption that the range of IMG usage shall be important. However, 
note that requirements for delivery properties may vary based on the 
usage scenario, and thus some limited-use implementations place less 
importance on some requirements. 


For example, it is clear that a multicast transport may provide more 
scalable delivery than a unicast transport; however, scalability 
requirements do not preclude the unicast transport mechanisms. In 
this sense, scalability is always important for the protocols 
irrespective of transport mechanisms. 
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5.2.1. Scalability 


REQ DEL-1: The IMG system MUST be scalable to large numbers of 
messages, so as to allow design and use of delivery mechanisms that 
will not fail in delivering up-to-date information under huge numbers 
of transactions and massive quantities of IMG metadata. 


REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from 
sending unnecessary IMG metadata that have been stored or deleted in 
IMG receivers. 


REQ DEL-3: The protocol MUST be scalable to very large audience sizes 
requiring IMG delivery. 


5.2.2. Support for Intermittent Connectivity 


REQ DEL-4: The system MUST enable IMG receivers with intermittent 
access to network resources (connectivity) to receive and adequately 
maintain sufficient IMG metadata. 


This allows intermittent access to save power where there is no need 
to keep communications links powered up while they are sitting idle. 
For instance, in this situation, periodic bursts of notifies ora 
fast cycling update carousel allow hosts to wake up for short periods 
of time and still be kept up-to-date. This can be beneficial for IMG 
receivers with sporadic connections to the fixed Internet, but is 
critical in the battery-powered wireless Internet. 


The implication of intermittent connectivity is that immediate 
distribution of changes becomes infeasible and so managing data 
consistency should be focused on the timely delivery of data. 


5.2.3. Congestion Control 


REQ DEL-5: Internet-friendly congestion control MUST be provided for 
use on the public Internet. 


REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when 
an IMG metadata item has lifetime information and its lifetime is 
over. This will lessen the need for notifications of updates from 
the IMG sender to the IMG receiver to invalidate the item and may 
help in reducing load. 


5.2.4. Sender- and Receiver-Driven Delivery 


REQ DEL-7: The system MUST be flexible in choosing sender-driven, 
receiver-driven, or both delivery schemes. 
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Sender-driven delivery achieves high scalability without interaction 
between the IMG sender and receiver. 


In contrast, receiver-driven delivery provides on-demand delivery for 
IMG receivers. Since an IMG sender’s complete IMG metadata may be a 
very large amount of data, the IMG receiver needs to be able to 
access the guide when convenient (e.g., when sufficient network 
bandwidth is available to the IMG receiver). 


5.3. Customized IMGs 
REQ CUS-1: The system MUST allow delivery of customized IMG metadata. 


The IMG receiver may require a subset of all the IMG metadata 
available according to their preferences (type of content, media 
description, appropriate age group, etc.) and configuration. 


The IMG receiver might send its preferences in the IMG operations 
that can specify user-specific IMG metadata to be delivered. These 
preferences could consist of filtering rules. When receiving these 
messages, the IMG sender might respond with appropriate messages 
carrying a subset of IMG metadata that matches the IMG receiver’s 
preferences. 


This mechanism can reduce the amount of IMG metadata delivered from 
the IMG sender to IMG receiver, and consequently it can save the 
resource consumption on the IMG entities and networks. It is 
typically useful in unicast cases and also beneficial in multicast 
cases where an IMG sender distributes the same IMG metadata to 
interested IMG receivers at the same time. 


For multicast and unicast cases where the IMG sender does not provide 
customized IMG metadata, the IMG receiver could receive all IMG 
metadata transmitted on the channels that the IMG receiver has 
joined. However, it may select and filter the IMG metadata to get 
customized IMG metadata by its preferences, and thus drop unwanted 
metadata immediately upon reception. 


Customizing metadata might be achieved by changing the IMG 
descriptions sent and IMG receivers and/or changing the delivery 
properties (channels used). 


Note that customization and scalability are only somewhat exclusive. 
Systems providing an IMG receiver to an IMG sender request-based 
customization will be generally less scalable to massive IMG receiver 
populations than those without this return signaling technique. 

Thus, customization, as with any feature that affects scalability, 
should be carefully designed for the intended application, and it may 
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not be possible that a one-size-fits-all solution for customization 
would meet the scalability requirements for all applications and 
deployment cases. 


5.4. Reliability 
5.4.1. Managing Consistency 


IMG metadata tends to change as time elapses; as new content is 
added, the old IMG metadata stored in the IMG receiver becomes 
unavailable, and the parameters of the existing IMG metadata are 
changed. 


REQ REL-1: The system MUST manage IMG metadata consistency. 


Either the IMG sender can simply make updates available 
(unsynchronized), or the IMG sender and receiver can interact to keep 
their copies of the IMG metadata synchronized. 


In the unsynchronized model, the IMG sender does not know whether a 
particular IMG receiver has an up-to-date copy of the IMG metadata. 


In the synchronized model, updating a cached copy of the IMG metadata 
is necessary to control consistency when the IMG sender or receiver 
could not communicate for a while. In this case, the IMG sender or 
receiver may need to confirm its consistency by IMG operations. 


REQ REL-2: Since IMG metadata can change at any time, IMG receivers 
SHOULD be notified of such changes. 


Fulfilling this requirement needs to be compatible with the 
scalability requirements for the number of IMG receivers and the 
consistency of metadata. 


Depending on the size of the IMG metadata, the interested party may 
want to defer retrieving the actual information. The change 
notification should be addressed to a logical user (or user group), 
rather than a host, since users may Change devices. 


Note that depending on the deployment environment and application 
specifics, the level of acceptable inconsistency varies. Thus, this 
document does not define inconsistency as specific time and state 
differences between IMG metadata stored in an IMG sender and IMG 
metadata stored in an IMG receiver. 


In general, the consistency of metadata for content and media is more 
important immediately prior to and during the media’s session(s). 
Hosts that forward (or otherwise resend) metadata may not tolerate 


Nomura, et al. Informational [Page 15] 


RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006 


inconsistencies because delivering out-of-date data is both 
misleading and bandwidth inefficient. 


5.4.2. Reliable Message Exchange 


REQ REL-4: An IMG transport protocol MUST support reliable message 
exchange. 


The extent to which this could result in 100% error-free delivery to 
100% of IMG receivers is a statistical characteristic of the 
protocols used. Usage of reliable IMG delivery mechanisms is 
expected to depend on the extent to which underlying networks provide 
reliability and, conversely, introduce errors. Note that some 
deployments of IMG transport protocols may not aim to provide perfect 
reception to all IMG receivers in all possible cases. 


5.5. IMG Descriptions 


REQ DES-1: IMG metadata MUST be interoperable over any IMG transport 
protocol, such that an application receiving the same metadata over 
any one (or more) of several network connections and/or IMG transport 
protocols will interpret the metadata in exactly the same way. (This 
also relates to the ' Independence of IMG Operations from IMG 
Metadata’ requirements.) 


REQ DES-2: IMG delivery MUST enable the carriage of any format of 
application-specific metadata. 


Thus, the system will support the description of many kinds of 
multimedia content, without the need for a single homogeneous 
metadata syntax for all uses (which would be infeasible anyway). 
This is essential for environments using IMG systems to support many 
kinds of multimedia content and to achieve wide applicability. 


REQ DES-3: Whereas specific applications relying on IMGs will need to 
select one or more specific application-specific metadata formats 
(standard, syntax, etc.), the IMG system MUST be independent of this 
(it may be aware, but it will operate in the same way for all). 


Thus, a metadata transfer envelope format that is uniform across all 
different application-specific IMG metadata formats is needed. The 
envelope would reference (point to) or carry (as payload) some 
application-specific metadata, and the envelope would support the 
maintenance of the application-specific metadata, which may also 
serve the metadata relationships determined by the data model (s) 
used. The envelope would not need to be aware of the data model(s) 
in use. 
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REQ DES-4: IMG metadata MUST be structured to enable fragmentation 
for efficient delivery. 


This is intended to ensure that an IMG sender with more than a 
trivial knowledge of metadata is able to deliver only part of its 
(and the global) complete IMG metadata knowledge. (For instance, a 
trivial quantity of knowledge could be a single SDP description.) In 
general, the resolution of this fragmentation will be very much 
dependent on the optimal delivery of a deployment, although some 
metadata syntaxes will inherently affect the sensible lower limit for 
a single element/fragment. 


REQ DES-5: A metadata transfer envelope MUST be defined to include 
essential parameters. 


Examples of essential parameters are those that allow the metadata in 
question to be uniquely identified and updated by new versions of the 
same metadata. 


REQ DES-6: It SHALL be possible to deduce the metadata format via the 
metadata transfer envelope. 


REQ DES-7: IMG senders SHALL use a metadata transfer envelope for 
each IMG metadata transfer. 


Thus, it will even be possible to describe relationships between 
syntactically dissimilar application-specific formats within the same 
body of IMG metadata knowledge. (For instance, a data model could be 
instantiated using both SDP and SDPng.) 


REQ DES-8: IMG metadata SHOULD support the description of differences 
between an updated version and an old version of IMG metadata when 
the IMG delivery mechanism carries updated IMG metadata and those 
differences are considerably little (e.g., by providing a ’delta’ of 
the two versions; this also relates the delivery property 
requirements for congestion control in Section 5.2.3). 


6. Security Considerations 


Internet Media Guides are used to convey information about multimedia 
resources from one or more IMG senders across one or more 
intermediaries to one or more IMG receivers. IMG metadata may be 
pushed to the IMG receivers or interactively retrieved by them. IMGs 
provide metadata as well as scheduling and rendezvous information 
about multimedia resources, and so on, and requests for IMG metadata 
may contain information about the requesting users. 
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The information contained in IMG metadata as well as the operations 
related to IMGs should be secured to avoid forged information, 
misdirected users, and spoofed IMG senders, for example, and to 
protect user privacy. 


The remainder of this section addresses the security requirements for 
IMGs. 


6.1. IMG Authentication and Integrity 


IMG metadata and its parts need to be protected against unauthorized 
alteration/addition/deletion on the way. Their originator needs to 
be authenticated. 


REQ AUT-1: It MUST be possible to authenticate the originator of a 
set of IMG metadata. 


REQ AUT-2: It MUST be possible to authenticate the originator of a 
subpart of IMG metadata (e.g., a delta or a subset of the 
information). 


REQ AUT-3: It MUST be possible to validate the integrity of IMG 
metadata. 


REQ AUT-4: It MUST be possible to validate the integrity of a subpart 
of IMG metadata (e.g., a delta or a subset of the information). 


REQ AUT-5: It MUST be possible to separate or combine individually 
authenticated pieces of IMG metadata (e.g., in an IMG transceiver) 
without invalidating the authentication. 


REQ AUT-6: It MUST be possible to validate the integrity of an 
individually authenticated piece of IMG metadata even after this 
piece has been separated from other pieces of IMG metadata and 
combined with other pieces to form new IMG metadata. 


REQ AUT-7: It MUST be possible to authenticate the originator of an 
IMG operation. 


REQ AUT-8: It MUST be possible to validate the integrity of any 


contents of an IMG operation (e.g., the subscription or inquiry 
information). 
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6.2. Privacy 


Customized IMG metadata and IMG metadata delivered by notification to 
individual users may reveal information about the habits and 
preferences of a user and may thus deserve confidentiality 
protection, even though the information itself is public. 


REQ PRI-1: It MUST be possible to keep user requests to subscribe to 
or retrieve certain (parts of) IMG metadata confidential. 


REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG 
metadata, or pointers to IMG metadata delivered to individual users 
or groups of users confidential. 


REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- 
to-end, that is, to prevent intermediaries (such as IMG transceivers) 
from accessing the contained information. 


6.3. Access Control for IMGs 


Some IMG metadata may be freely available, while access to other IMG 
metadata may be restricted to closed user groups (e.g., paying 
subscribers). Also, different parts of IMG metadata may be protected 
at different levels: for example, metadata describing a media session 
may be freely accessible, while rendezvous information to actually 
access the media session may require authorization. 


REQ ACC-1: It MUST be possible to authorize user access to IMG 
metadata. 


REQ ACC-2: It MUST be possible to authorize access of users to pieces 
of IMG metadata (delta information, subparts, pointers). 


REQ ACC-3: It MUST be possible to require different authorization for 
different parts of the same IMG metadata. 


REQ ACC-4: It MUST be possible to access selected IMG metadata 
anonymously. 


REQ ACC-5: It MUST be possible for an IMG receiver to choose not to 
receive (parts of) IMG metadata in order to avoid being identified by 
the IMG sender. 


REQ ACC-6: It SHOULD be possible for an IMG transceiver to select 


suitable authorization methods that are compatible between both IMG 
senders and IMG receivers it interacts with. 
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REQ ACC-7: It MAY be possible for IMG senders to require certain 
authorization that cannot be modified by intermediaries. 


6.4. Denial-of-Service (DOS) Attacks 


Retrieving or distributing IMG metadata may require state in the IMG 
senders, transceivers, and/or receivers for the respective IMG 
transport sessions. Attackers may create large numbers of sessions 
with any of the above IMG entities to disrupt regular operation. 


REQ DOS-1: IMG operations SHOULD be authenticated. 


REQ DOS-2: It SHOULD be possible to avoid DoS attacks that build up 
session state in IMG entities to exhaust their resources. 


REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust 
resources of IMG entities by flooding them with IMG metadata. 


As an example, two potential solutions that may be considered are 
running an IMG entity in stateless mode or identification and 
discarding of malicious packets by an IMG entity. 


6.5. Replay Attacks 


IMG metadata disseminated by an IMG sender or an IMG transceiver may 
be updated, be deleted, or lose validity over time for some other 
reasons. Replaying outdated IMG metadata needs to be prevented. 


Furthermore, replay attacks may also apply to IMG operations (rather 
than just their payload). Replaying operations also needs to be 
prevented. 


REQ REP-1: IMG metadata MUST be protected against partial or full 
replacement of newer ("current") versions by older ones. 


In a system with multiple senders, it may not be feasible to prevent 
some senders from delivering older versions of metadata than others - 
as a result of imperfect sender-sender data consistency. Thus, 
replay attacks and delivery of inconsistent data require that an IMG 
receiver verifies that the IMG metadata is valid and reliable by 
using some security mechanism(s) (e.g., authorization, 
authentication, or integrity). 


REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on 
the IMG operations. 
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The level of threat from replay attacks varies very much depending on 
system scale and how well defined or open it is. Thus, mitigating 
replay attacks may lead to different solutions for different systems, 
independent of the basic delivery method and metadata definitions. A 
system with multiple senders presents a more challenging scenario for 
handling replay attacks. As an example, bundling metadata with a 
security mechanism is one potential solution. 
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